home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / info-service / gopher / Unix / xgopher.1.3 / Documents / Sun-names < prev    next >
Encoding:
Text File  |  1993-05-25  |  5.7 KB  |  129 lines
  1.         Host computer name resolution on a Sun Machine 
  2.     ==============================================
  3.  
  4.    +----------------------------------------------------------------------+
  5.    | If you are running Xgopher on a Sun computer system (e.g., Sun4,     |
  6.    | Sparc, etc.) and see error messages such as:                         |
  7.    |                                                                      |
  8.    |   Cannot establish a network connection                              |
  9.    |   (could not identify the remote host computer xxx.xxx.xxx.xxx)      |
  10.    |                                                                      |
  11.    | then read this document.                                             |
  12.    +----------------------------------------------------------------------+
  13.  
  14.  
  15. Background
  16. ----------
  17.  
  18. Gopher connects to other machines all around the internet, often
  19. without your knowledge.  Machine names are provided as human-readable
  20. "hostnames".  For example, harpoon.cso.uiuc.edu.  The first part of this
  21. name is the specific host (harpoon), the rest is the "domain" name.
  22. The long form of the name, with .cso.uiuc.edu at the end is called
  23. the "fully qualified domain name.
  24. Each registered name is mapped to a unique numeric IP address.  For our
  25. purposes, we will assume that all the computers we are working with 
  26. have properly registered names.  The example above, harpoon, has the
  27. unique IP address of 128.174.33.160.  All numeric addresses look
  28. something like this; 4 sets of numbers separated by dots.
  29.  
  30. Xgopher uses the built in networking software of a computer system to
  31. make a connection to another computer.  Xgopher may supply either
  32. the fully qualified name or the IP address of another machine.
  33. Usually, the name is provided.  This name is converted to the address
  34. by a process called "name resolution".  This is the seat of the problem!
  35.  
  36. In the old days, every host name and its numeric IP address were stored
  37. together in a table in a file called /etc/hosts on a Unix system.
  38. You will still find a small version of this file on most systems.
  39. With MILLIONS of computers in the world, more being added every minute,
  40. and many of them changing their addresses for various reasons, it is
  41. IMPOSSIBLE to maintain this table in /etc/hosts anymore.
  42.  
  43. Today we use a program called a "name server" to resolve a hostname
  44. into an IP address.
  45.  
  46. If you get errors such as the one shown at the top of this document,
  47. then read on.
  48.  
  49. Solutions
  50. ---------
  51. You may be able to just relink with a different library (or no library).
  52. I have had some people say that they need to use -lresolv
  53. on the load command to get Xgopher to work, and others that insist
  54. that -lresolve NOT be used since then Xgopher will use the NIS
  55. name server for resolving the address.  Whichever way you linked
  56. Xgopher (with or without -lresolv), please try it the other way.
  57. If this works, great!
  58.  
  59. Verify that your network does talk to the outside world, and is
  60. reasonalby open.  For some people, especially those in commercial
  61. or government sites, your host may be behind a "firewall" - a 
  62. restriction to prevent unauthorized access to your network and
  63. computing facilities.  There may also be restrictions on which ports may
  64. be used for outside connections.  Gopher uses port 70 for most 
  65. communication, but may use other ports.
  66.  
  67. If this isn't the problem, then it may be the use of a name server
  68. (or lack thereof).
  69.  
  70.  
  71. Name Servers
  72. ------------
  73.  
  74. Solution 1.
  75.     Sun supplies a system called NIS, Network Information Service".  If
  76.     you run NIS on your system it servers as the name server and Xgopher
  77.     should work.
  78.  
  79.     This process is simple to setup and is normally handled by your system
  80.     administrator.  Ask your local administrator for assistance if this is
  81.     not already setup on your system. If you are the admin, you need to
  82.     uncomment the B=-b line in your NIS Makefile and create the
  83.     /etc/resolv.conf file.
  84.  
  85.     There are some arguments for not using NIS, but this is normally
  86.     an site-dependent policy decision.
  87.  
  88.  
  89. Solution 2.
  90.     Another solution documented by Sun Microsystems, Inc, but not
  91.     supported by them is to modify libc.so (the basic C language
  92.     run-time library used by nearly every program) to include the
  93.     subroutines gethostby* (gethostbyname, gethostbyaddr).  They
  94.     are already supplied with your system, you just need to rebuild
  95.     libc.so.  Every program you compile from then on will have access
  96.     to these routines which will connect to a "nearby" name server
  97.     (magic!).  This route isn't for everyone, but if you want to 
  98.     try it, see the document Sunlib-rebuild in this directory.
  99.  
  100.  
  101. Conclusion
  102. ----------
  103.  
  104. Your best solution is to find the Sun system's administrator for
  105. you site and get some guidance based on the information you are now
  106. armed with.  If you happen to be the system's administrator, then
  107. choose one of the above methods and implement it.
  108.  
  109. If you are having these problems, your are not alone, nor is your problem
  110. confined to Xgopher.  Any network application would provide similar grief.
  111.  
  112. This is a frequent discussion item in the news group comp.sys.sun.admin.
  113. I recommend that if you are still experiencing problems, that you 
  114. follow up with a question to this discussion group.
  115.  
  116.  
  117. Thanks
  118. ------
  119.  
  120. So many people have written to me of this problem.  A small number have
  121. provided the information and clues that allowed me to put together this
  122. document.  I particularly want to thank our Sun System Support individual
  123. on our campus, Steven Miller for really setting me straight on all of this,
  124. suggestion the solutions, and proofreading this document.
  125.  
  126. R.Stewart(Stew) Ellis, (Humanities & Social Science,  GMI Eng.& Mgmt. Inst.,
  127. Flint, MI 48504, ellis@nova.gmi.edu) made a coherent posting to the
  128. comp.infosystems.gopher newsgroup providing similar information.
  129.